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1. Introduction 

This document provides recommendations for the implementation of pubHc-key 
cryptography based on the RSA algorithm [18], covering the following aspects: 

• cryptographic primitives 

• encryption schemes 

• signature schemes with appendix 

• ASN.l syntax for representing keys and for identifying the schemes 

The recommendations are intended for general application within computer and 
communications systems, and as such include a fair amount of flexibility. It is expected 
that application standards based on these specifications may include additional 
constraints. The recommendations are intended to be compatible with draft standards 
currently being developed by the ANSI X9F1 [1] and IEEE P1363 working groups [14]. 

This docimient supersedes PKCS #1 version 1.5 [20]. 
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Editor's note. It is expected that subsequent versions of PKCS #1 may cover other 
aspects of the RSA algorithm such as key size, key generation, key validation, and 
signature schemes with message recovery. 

1.1 Overview 

The organization of this document is as follows: 

• Section 1 is an introduction. 

• Section 2 defines some notation used in this document. 

• Section 3 defines the RSA pubUc and private key types. 

• Sections 4 and 5 define several primitives, or basic mathematical operations. Data 
conversion primitives are in Section 4, and cryptographic primitives (encryption- 
decryption, signature- verification) are in Section 5. 

• Section 6, 7 and 8 deal with the encryption and signature schemes in this document. 
Section 6 gives an overview. Section 7 defines an OAE? -based [2] encryption scheme 
along with the method found in PKCS #1 vl.5. Section 8 defines a signature scheme 
with appendix; the method is identical to that of PKCS #1 vl.5. 

• Section 9 defines the encoding methods for the encryption and signature schemes in 
Sections 7 and 8. 

• Section 10 defines the hash fimctions and the mask generation fimction used in this 
document. 

• Section 11 defines the ASN.l syntax for the keys defined in Section 3 and the 
schemes in Sections 7 and 8. 

• Section 1 2 outlines the revision history of PKCS # 1 . 

• Section 13 contains references to other publications and standards. 



2. Notation 

(n, e) RSA public key 

c ciphertext representative, an integer between 0 and nA 

C ciphertext, an octet string 

d private exponent 

dP p's exponent, a positive integer such that: 

e't/P=l (mod(p-l)) 

dQ q's exponent, a positive integer such that: 

e £/(3=l (mod(^-l)) 

e public exponent 

EM encoded message, an octet string 

emLen intended length in octets of an encoded message 
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H hash value, an output of Hash 

Hash hash function 

hLen output length in octets of hash function Hash 

K RSA private key 

k length in octets of the modulus 

/ intended length of octet string 

lcm( . , .) least common multiple of two nonnegative integers 

m message representative, an integer between 0 and nA 

M message, an octet string 

MGF mask generation function 

n modulus 

P encoding parameters, an octet string 

q prime factors of the modulus 

qlnv CRT coefficient, a positive integer less than p such that: 

q • qlnv = 1 (mod p) 

s signature representative, an integer between 0 and n-l 

S signature, an octet string 

X a nonnegative integer 

X an octet string corresponding to X 

\xor bitwise exclusive-or of two octet strings 

X{n) lcm(p- 1,9-1), where n = pq 

II concatenation operator 

II . II octet length operator 



3. Key types 

Two key types are employed in the primitives and schemes defined in this document: 
RSA public key and RSA private key. Together, an RSA public key and an RSA private 
key form an RSA key pair. 

3,1 RSA public key 

For the purposes of this document, an RSA public key consists of two components: 
— «, the modulus, a normegative integer 
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— e, the public exponent, a nonnegative integer 

In a valid RSA public key, the modulus « is a product of two odd primes p and q, and the 
public exponent e is an integer between 3 and n-l satisfying gcd (e, X{n)) = 1, where X(n) 
= 1cm (p- 1,^-1). 

A recommended syntax for interchanging RSA public keys between implementations is 
given in Section 1 1.1.1; an implementation's internal representation may differ. 

3.2 RSA private key 

For the purposes of this document, an RSA private key may have either of two 
representations. 

1. The first representation consists of the pair («, d), where the components have the 
following meanings: 

— /?, the modulus, a nonnegative integer 

— J, the private exponent, a nonnegative integer 

2, The second representation consists of a quintuple (p, dP, dQ, qlnv), where the 
components have the following meanings: 

— p, the first factor, a nonnegative integer 

— 9, the second factor, a nonnegative integer 

— dP, the first factor's exponent, a nonnegative integer 

— dQ, the second factor's exponent, a nonnegative integer 

— qlnv, the CRT coefficient, a nonnegative integer 

In a valid RSA private key with the first representation, the modulus n is the same as in 
the corresponding public key and is the product of two odd primes p and q, and the 
private exponent J is a positive integer less than n satisfying 

e * J = 1 (mod X{n)) 

where e is the corresponding public exponent and X{n) is as defined above. 

In a valid RSA private key with the second representation, the two factors p and 9 are the 
prime factors of the modulus w, the exponents dP and dQ are positive integers less than/? 
and ^ respectively satisfying 
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e-dP^l (mod (p-l)) 
e 'dQ= I (mod 



and the CRT coefficient qJnv is a positive integer less thanp satisfying 



q ' qlnv = 1 (mod /?). 



A recommended syntax for interchanging RSA private keys betv^een implementations, 
which includes components from both representations, is given in Section 11.1.2; an 
implementation's internal representation may differ. 

4. Data conversion primitives 

Two data conversion primitives are employed in the schemes defined in this document: 

• I20SP - Integer-to-Octet-String primitive 

• 0S2IP - Octet-String-to-Integer primitive 

For the purposes of this document, and consistent with ASN.l syntax, an octet string is an 
ordered sequence of octets (eight-bit bytes). The sequence is indexed from first 
(conventionally, leftmost) to last (rightmost). For purposes of conversion to and from 
integers, the first octet is considered the most significant in the following conversion 
primitives 

4.1 I20SP 

I20SP converts a nonnegative integer to an octet string of a specified length. 
I20SP(x,/) 

Input: X nonnegative integer to be converted 



intended length of the resulting octet string 



Output: 



X 



corresponding octet string of length /; or "integer too large' 



Steps: 



1. 



Ifx > 256', output "integer too large" and stop. 



2. 



Write the integer jc in its unique /-digit representation base 256: 



X = ;c^i 256 + Jc^2 256 + . . . + x, 256 + x^ 
where 0 < x,. < 256 (note that one or more leading digits will be zero if 
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x<256^')- 

3. Let the octet Xi haVe the value for !</</. Output the octet string 
4.2 0S2IP 

0S2P converts an octet string to a nonnegative integer. 
0S2IP {X) 

Input: X octet string to be converted 

Output: X corresponding nonnegative integer 
Steps: 

1 . Let ^, . . . Xi be the octets oiX from first to last, and let X;.,. have value X^ for 1 < 
i</. 

2. Let X = x^^ 256 + x^-^ 256 '"^ + . . . + 256 + ;co. 

3. Outputs. 

5. Cryptographic primitives 

Cryptographic primitives are basic mathematical operations on which cryptographic 
schemes can be built. They are intended for implementation in hardware or as software 
modules, and are not intended to provide security apart from a scheme. 

Four types of primitive are specified in this document, organized in pairs: encryption and 
decryption; and signature and verification. 

The specifications of the primitives assume that certain conditions are met by the inputs, 
in particular that public and private keys are valid. 

5.1 Encryption and decryption primitives 

An encryption primitive produces a ciphertext representative from a message 
representative under the control of a public key, and a decryption primitive recovers the 
message representative from the ciphertext representative under the control of the 
corresponding private key. 
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One pair of encryption and decryption primitives is employed in the encryption schemes 
defined in this document and is specified here: RSAEP/RSADP. RSAEP and RSADP 
involve the same mathernatical operation, with different keys as input. 

The primitives defined here are the same as in the draft IEEE PI 363 and are compatible 
withPKCS#l vl.5. 

The main mathematical operation in each primitive is exponentiation. 

5.1.1 RSAEP 

RSAEP ((n, elm) 

Input: (n, e) RSA public key 

m message representative, an integer between 0 and n-1 

Output: c ciphertext representative, an integer between 0 and or 

"message representative out of range" 

Assumptions: public key (w, e) is valid 

Steps: 

1. If the message representative m is not between 0 and w-l, output "message 
representative out of range" and stop. 

2. Let c = mod n. 

3. Output c. 

5.1.2 RSADP 

RSADP (i:,c) 

Input: K RSA private key, where K has one of the following forms: 

— a pair {n^d) 

—a quintuple (p, 9, JP, i/g, ^//iv) 

c ciphertext representative, an integer between 0 and n-1 

Output: m ' message representative, an integer between 0 and nA; or 

"ciphertext representative out of range" 
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Assumptions: private key AT is valid 
Steps: 

1. If the ciphertext representative c is not between 0 and n-l, output "ciphertext 
representative out of range" and stop. 

2. If the first form {n, d) of AT is used: 

2.1 Let /n = c'' mod «, 

Else, if the second form (p, q, dP, dQ, qlnv) ofK is used: 

2.2 Lctnif^c'^^modp. 

2.3 Let = c''^ mod 9. 

2.4 Let A = ^//iv ( - ) mod p. 

2.5 LcXm-m2-^ h q, 

3. Output m. 

5.2 Signature and verification primitives 

A signature primitive produces a signature representative from a message representative 
under the control of a private key, and a verification primitive recovers the message 
representative from the signature representative under the control of the corresponding 
public key. One pair of signature and verification primitives is employed in the signature 
schemes defined in this document and is specified here: RSASPl/RSAVPl . 

The primitives defined here are the same as in the draft IEEE PI 363 and are compatible 
with PKCS #1 vl.5. 

The main mathematical operation in each primitive is exponentiation, as in the encryption 
and decryption primitives of Section 5.1. RSASPl and RSAVPl are the same as RSADP 
and RSAEP except for the names of their input and output arguments; they are 
distinguished as they are intended for different purposes. 

5.2.1 RSASPl 

RSASPl {K,m) 

Input: K RSA private key, where a: has one of the following forms: 

— a pair {n,d) 
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— a quintuple (p, q, dP, dQ^ qlnv) 

m message representative, an integer between 0 and n- 1 

Output: s signature representative, an integer between 0 and w-l ; or 

"message representative out of range" 

Assumptions: private key AT is valid 
Steps: 

1. If the message representative m is not between 0 and output "message 
representative out of range" and stop. 

2. Ifthe first form (77, J) of Misused: 

2.1 Let ^ = /M*' mod «. 

Else, if the second form (p, q, dP, dQ, qlnv) of K is used: 

2.2 Let 5/ = m''^ mod p. 

2.3 Let S2 = m"^^ mod q. 

2.4 Ltt h ^ qlnv {Sj -32) mod p. 

2.5 Let 5 = 5^ -I- A ^. 

3. Outputs. 

5.2.2 RSAVPl 

RSAVPl 

Input: («, e) RSA public key 

s signature representative, an integer between 0 and n-1 
Output: m message representative, an integer between 0 and n-1 ; or "invalid" 
Assumptions: public key (n, e) is valid 
Steps: 

1. If the signature representative s is not between 0 and /2-I, output "invalid" and 
stop. 
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2. 



Let m=s^ mod n. 



3. Outputs. 

6. Overview of schemes 

A scheme combines cryptographic primitives and other techniques to achieve a particular 
security goal. Two types of scheme are specified in this document: encryption schemes 
and signature schemes with appendix. 

The schemes specified in this document are limited in scope in that their operations 
consist only of steps to process data with a key, and do not include steps for obtaining or 
validating the key. Thus, in addition to the scheme operations, an application will 
typically include key management operations by which parties may select public and 
private keys for a scheme operation. The specific additional operations and other details 
are outside the scope of this document. 

As was the case for the cryptographic primitives (Section 5), the specifications of scheme 
operations assume that certain conditions are met by the inputs, in particular that public 
and private keys are valid. The behavior of an implementation is thus unspecified when a 
key is invalid. The impact of such unspecified behavior depends on the application. 
Possible means of addressing key validation include explicit key validation by the 
application; key validation within the public-key infi^astructure; and assignment of 
liability for operations performed with an invalid key to the party who generated the key. 

7. Encryption schemes 

An encryption scheme consists of an encryption operation and a decryption operation^ 
where the encryption operation produces a ciphertext fi-om a message with a recipient's 
public key, and the decryption operation recovers the message fi-om the ciphertext with 
the recipient's corresponding private key. 

An encryption scheme can be employed in a variety of applications. A typical application 
is a key establishment protocol, where the message contains key material to be delivered 
confidentially fi-om one party to another. For instance, PKCS #7 [21] employs such a 
protocol to deliver a content-encryption key from a sender to a recipient; the encryption 
schemes defined here would be suitable key-encryption algorithms in that context. 

Two encryption schemes are specified in this document: RSAES-OAEP and RSAES- 
PKCSl-vl_5. RSAES-OAEP is recommended for new applications; RSAES-PKCSl- 
vl_5 is included only for compatibility with existing applications, and is not 
recommended for new applications. 
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The encryption schemes given here follow a general model similar to that employed in 
IEEE PI 363, by combining encryption and decryption primitives with an encoding 
method for encryption. The encryption operations apply a message encoding operation to 
a message to produce an encoded message, which is then converted to an integer message 
representative. An encryption primitive is applied to the message representative to 
produce the ciphertext. Reversing this, the decryption operations apply a decryption 
primitive to the ciphertext to recover a message representative, which is then converted to 
an octet string encoded message. A message decoding operation is applied to the encoded 
message to recover the message and verify the correctness of the decryption. 

7.1 RSAES-OAEP 

RSAES-OAEP combines the RSAEP and RSADP primitives (Sections 5.1.1 and 5.1.2) 
with the EME-OAEP encoding method (Section 9.1.1) EME-OAEP is based on the 
method found in [2]. It is compatible with the EFES scheme defined in the draft PI 363 
where the encryption and decryption primitives are IFEP-RSA and IFDP-RSA and the 
message encoding method is EME-OAEP. RSAES-OAEP can operate on messages of 
length up to k-l-lhLen octets, where hLen is the length of the hash function output for 
EME-OAEP and k is the length in octets of the recipient's RSA modulus. 

Assuming that the hash function in EME-OAEP has appropriate properties, and the key 
size is sufficiently large, RSAEP-OAEP provides "plaintext-aware encryption," meaning 
that it is computationally infeasible to obtain full or partial information about a message 
from a ciphertext, and computationally infeasible to generate a valid ciphertext without 
knowing the corresponding message. Therefore, a chosen ciphertext attack is ineffective 
against a plaintext-aware encryption scheme such as RSAES-OAEP. We briefly note that 
to receive the full security benefit of RSAES-OAEP, it should not be used in a protocol 
involving RSAES-PKCSl-vl_5. It is possible that in a protocol in which both encryption 
schemes are present, an adaptive chosen ciphertext attack such as [4] would be useful. 

Both the encryption and the decryption operations of RSAES-OAEP take the value of the 
parameter string P as input. In this version of PKCS #1, P is an octet string that is 
specified explicitly. See Section 11.2.1 for the relevant ASN.l syntax. 

7.1.1 Encryption operation 

RSAES-OAEP-Encrypt ((w, e), M,F) 

Input: (w, e) recipient's RSA public key 

M message to be encrypted, an octet string of length at most k-l" 
IhLen, where k is the length in octets of the modulus n and hLen is 
the length in octets of the hash function output for EME-OAEP 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 v2.0: RSA ;^GRAPHY STANDARD 



13 



P encoding parameters, an octet string that may be empty 
Output: C cipliertext, an octet string of length k\ or "message too long" 
Assumptions: public key (w, e) is valid 
Steps: 

1. Apply the EME-OAEP encoding operation (Section 9.1.1.2) to the message M 
and the encoding parameters P to produce an encoded message EM of length ^-1 
octets: 

EM = EME-0 AEP-Encode (M, P,kA) 

If the encoding operation outputs "message too long," then output "message too 
long" and stop. 

2. Convert the encoded message EM to an integer message representative m: 

m = 0S2IP (EM) 

3. Apply the RSAEP encryption primitive (Section 5.1 ,1) to the public key («, e) and 
the message representative m to produce an integer ciphertext representative c: 

c = RSAEP ((/I, e\ m) 

4. Convert the ciphertext representative c to a ciphertext C of length k octets: 

C = I20SP(c,^) 

5. Output the ciphertext C 

7.1.2 Decryption operation 

RSAES-OAEP-Decrypt {K, C, P) 

Input: K recipient's RSA private key 

C ciphertext to be decrypted, an octet string of length where k is 
the length in octets of the modulus n 

P encoding parameters, an octet string that may be empty 

Output: M message, an octet string of length at most k-l-lhLen, where hLen is 

the length in octets of the hash function output for EME-OAEP; or 
"decryption error" 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 V2.0: RSA aW. , jraphy Standard 



14 



Steps: 

1 . If the length of the ciphertext C is not k octets, output "decryption error" and stop. 

2. Convert the ciphertext C to an integer ciphertext representative c: 

c = 0S2IP(C) 

3. Apply the RSADP decryption primitive (Section 5.1.2) to the private key K and 
the ciphertext representative c to produce an integer message representative m\ 

m = RSADP (i^,c) 

If RSADP outputs "ciphertext out of range," then output "decryption error" and 
stop. 

4. Convert the message representative m to an encoded message EM of length k-\ 
octets: 

'£M=I20SP(w,^-l) 
If I20SP outputs "integer too large," then output "decryption error" and stop. 

5. Apply the EME-OAEP decoding operation to the encoded message EM and the 
encoding parameters P to recover a message M: 

M= EME-OAEP-Decode (fA/, P) 

If the decoding operation outputs "decoding error," then output "decryption error" 
and stop. 

6. Output the message Af. 

Note, It is important that the error messages output in steps 4 and 5 be the same, 
otherwise an adversary may be able to extract useful information from the type of error 
message received. Error message information is used to mount a chosen ciphertext attack 
on PKCS #1 vl.5 encrypted messages in [4]. 

7.2 RSAES-PKCSl-vl_5 

RSAES-PKCSl-vl_5 combines the RSAEP and RSADP primitives with the EME- 
PKCSl-vl_5 encoding method. It is the same as the encryption scheme in PKCS #1 vl.5. 
RSAES-PKCSl-vl_5 can operate on messages of length up to ^-11 octets, although care 
should be taken to avoid certain attacks on low-exponent RS A due to Coppersmith, et al. 
when long messages are encrypted (see the third bullet in the notes below and [7]). 
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RSAES-PKCSl-vl_5 does not provide "plaintext aware" encryption. In particular, it is 
possible to generate valid ciphertexts without knowing the corresponding plaintexts, with 
a reasonable probability of success. This ability can be exploited in a chosen ciphertext 
attack as shown in [4]. Therefore, if RSAES-PKCSl-vl_5 is to be used, certain easily 
implemented countermeasures should be taken to thwart the attack found in [4]. The 
addition of structure to the data to be encoded, rigorous checking of PKCS #1 vl.5 
conformance and other redundancy in decrypted messages, and the consolidation of error 
messages in a client-server protocol based on PKCS #1 vl.5 can all be effective 
countermeasures and don't involve changes to a PKCS #1 vl.5-based protocol. These and 
other countermeasures are discussed in [5]. 

Notes. The following passages describe some security recommendations pertaining to the 
use of RSAES-PKCSl-vl_5. Recommendations from version 1.5 of this document are 
included as well as new recommendations motivated by cryptanalytic advances made in 
the intervening years. 

• It is recommended that the pseudorandom octets in EME-PKCSl-vl_5 be generated 
independently for each encryption process, especially if the same data is input to more 
than one encryption process. Hastad's results [13] are one motivation for this 
recommendation. 

• The padding string PS in EME-PKCSl-vl_5 is at least eight octets long, which is a 
security condition for public-key operations that prevents an attacker from recovering 
data by trying all possible encryption blocks. 

• The pseudorandom octets can also help thwart an attack due to Coppersmith et al. [7] 
when the size of the message to be encrypted is kept small. The attack works on low- 
exponent RSA when similar messages are encrypted with the same public key. More 
specifically, in one flavor of the attack, when two inputs to RSAEP agree on a large 
fraction of bits (8/9) and low-exponent RSA {e = 3) is used to encrypt both of them, it 
may be possible to recover both inputs with the attack. Another flavor of the attack is 
successful in decrypting a single ciphertext when a large fraction (2/3) of the input to 
RSAEP is already known. For typical applications, the message to be encrypted is 
short (e.g., a 128-bit symmetric key) so not enough infomiation will be known or 
common between two messages to enable the attack. However, if a long message is 
encrypted, or if part of a message is known, then the attack may be a concern. In any 
case, the RSAEP-OAEP scheme overcomes the attack. 

1J2A Encryption operation 

RSAES-PKCS1-v1_5-Encrypt ((w, e), M) 
Input: (n, e) recipient's RSA public key 
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M message to be encrypted, an octet string of length at most k-W 
octets, where k is the length in octets of the modulus n 

Output: C ciphertext, an octet string of length kr, or "message too long" 

Steps: 

1. Apply the EME-PKCSl-vl_5 encoding operation (Section 9.1.2.1) to the message 
M to produce an encoded message EM of length kA octets: 

jE:M= EME-PKCS1-v1_5-Encode (M, k-\) 

If the encoding operation outputs "message too long," then output "message too 
long" and stop. 

2. Convert the encoded message EM to an integer message representative m: 

m^0S>2W{EM) 

3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public key (w, e) and 
the message representative m to produce an integer ciphertext representative c: 

c = RSAEP ((n, e), m) 

4. Convert the ciphertext representative c to a ciphertext C of length k octets: 

C = I20SP(c,Jt) 

5. Output the ciphertext C. 

7.2.2 Decryption operation 

RSAES-PKCS1-v1_5-Decrypt {K, C) 

Input: K recipient's RSA private key 

C ciphertext to be decrypted, an octet string of length K where k is 
the length in octets of the modulus /I 

Output: M message, an octet string of length at most ^-11; or "decryption 

error" 

Steps: 

1 . If the length of the ciphertext C is not k octets, output "decryption error" and stop. 

2. Convert the ciphertext C to an integer ciphertext representative c: 
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c = 0S2IP(O 

3. Apply the RSADP decryption primitive to the private key (/i, d) and the ciphertext 
representative c to produce an integer message representative m: 

m = RSAD?{{n,d),c) 

If RSADP outputs "ciphertext out of range " then output "decryption error" and 
stop. 

4. Convert the message representative m to an encoded message EM of length ^-1 
octets: 

EM=120S?{m,kA) 
If I20SP outputs "integer too large," then output "decryption error" and stop. 

5. Apply the EME-PKGSl-vl_5 decoding operation to the encoded message EM to 
recover a message M: 

M = EME-PKCSl-vl_5-DECODE (EM) 

If the decoding operation outputs "decoding error," then output "decryption error" 
and stop. 

6. Output the message M. 

Note, It is important that only one type of error message is output by EME-PKCSl-vl_5, 
as ensured by steps 4 and 5. If this is not done, then an adversary may be able to use 
information extracted form the type of error message received to mount a chosen 
ciphertext attack such as the one found in [4]. 

8. Signature schemes with appendix 

A signature scheme with appendix consists of a signature generation operation and a 
signature verification operation, where the signature generation operation produces a 
signature from a message with a signer's private key, and the signature verification 
operation verifies the signature on the message with the signer's corresponding public 
key. To verify a signature constructed with this type of scheme it is necessary to have the 
message itself. In this way, signature schemes with appendix are distinguished from 
signature schemes with message recovery, which are not supported in this document. 

A signature scheme with appendix can be employed in a variety of applications. For 
instance, X.509 [6] employs such a scheme to authenticate the content of a certificate; the 
signature scheme with appendix defined here would be a suitable signature algorithm in 
that context. A related signature scheme could be employed in PKCS #7 [21], although 
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for technical reasons, the current version of PKCS #7 separates a hash function from a 
signature scheme, which is different than what is done here. 

One signature scheme with appendix is specified in this document: RSASSA-PKCSl- 
vl_5. 

The signature scheme with appendix given here follows a general model similar to that 
employed in IEEE PI 363, by combining signature and verification primitives with an 
encoding method for signatures. The signature generation operations apply a message 
encoding operation to a message to produce an encoded message, which is then converted 
to an integer message representative. A signature primitive is then applied to the message 
representative to produce the signattire. The signature verification operations apply a 
signature verification primitive to the signature to recover a message representative, 
which is then converted to an octet string. The message encoding operation is again 
applied to the message, and the result is compared to the recovered octet string. If there is 
a match, the signatxire is considered valid. (Note that this approach assumes that the 
signature and verification primitives have the message-recovery form and the encoding 
method is detemiinistic, as is the case for RSASPl/RSAVPl and EMSA-PKCSl-vl_5. 
The signature generation and verification operations have a different form in PI 363 for 
other primitives and encoding methods.) 

Editors note, RSA Laboratories is investigating the possibility of including a scheme 
based on the PSS encoding methods specified in [3], which would be recommended for 
new applications. 

8.1 RSASSA.PKCSl-vl_5 

RSASSA-PKCSl-vl_5 combines the RSASPl and RSAVPl primitives with the EME- 
PKCSl-vl_5 encoding method. It is compatible with the IFSSA scheme defined in the 
draft PI 363 where the signature and verification primitives are IFSP-RSAl and IFVP- 
RSAl and the message encoding method is EMSA-PKCSl-vl_5 (which is not defined in 
P1363), The length of messages on which RSASSA-PKCSl-vl_5 can operate is either 
unrestricted or constrained by a very large number, depending on the hash function 
underlying the message encoding method. 

Assuming that the hash function in EMSA-PKCSl-vl_5 has appropriate properties and 
the key size is sufficiently large, RSASSA-PKCSl-vl_5 provides secure signatures, 
meaning that it is computationally infeasible to generate a signature without knowing the 
private key, and computationally infeasible to find a message with a given signature or 
two messages with the same signature. Also, in the encoding method EMSA-PKCSl- 
vl_5, a hash function identifier is embedded in the encoding. Because of this feature, an 
adversary must invert or find collisions of the particular hash function being used; 
attacking a different hash function than the one selected by the signer is not useful to the 
adversary. 
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8.1.1 Signature generation operation 

RSASSA-PKCSl-vl_5-SiGN (K, M) 

Input: K signer's RSA private key 

M message to be signed, an octet string 

Output: S signature, an octet string of length k, where k is the length in octets 

of the modulus n ; "message too long" or "modulus too short" 

Steps: 

1 . Apply the EMSA-PKCSl-vl_5 encoding operation (Section 9.2.1) to the message 
A/ to produce an encoded message £M of length k-\ octets: 

£M= EMSA-PKCS1-v1_5-Encode (M, k-\) 

If the encoding operation outputs "message too long," then output "message too 
long" and stop. If the encoding operation outputs "intended encoded message 
length too short" then output "modulus too short". 

2. Convert the encoded message EM to an integer message representative m: 

m = 0S2IP (EM) 

3. Apply the RSASPl signature primitive (Section 5.2.1) to the private key K and 
the message representative m to produce an integer signature representative s: 

s = RSASPl (K, m) 

4. Convert the signature representative 5 to a signature S of length k octets: 

5 = I20SP(j,^) 

5. Output the signature S. 

8.1.2 Signature verification operation 

RSASSA-PKCS1-v1_5-Verify ((/i, e), M. S) 

Input: (/I, e) signer's RSA public key 

M message whose signature is to be verified, an octet string 

5 signature to be verified, an octet string of length k, where k is the 
length in octets of the modulus n 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 v2.0: RSA CW jgraphy Standard 



20 



Output: "valid signature," "invalid signature," or "message too long", or "modulus 
too short" 

Steps: 

1 . If the length of the signature S is not k octets, output "invalid signature" and stop. 

2. Convert the signature 5 to an integer signature representative s: 

5 = OS2IP(5) 

3. Apply the RSAVPl verification primitive (Section 5.2.2) to the public key («, e) 
and the signature representative s to produce an integer message representative m: 

m = RSAVPl (in, els) 

If RSAVPl outputs "invalid" then output "invalid signature" and stop. 

4. Convert the message representative ;m to an encoded message EM of length ^-1 
octets: 

£M=I20SP(m,/:-l) 
If I20SP outputs "integer too large," then output "invalid signature" and stop. 

5. Apply the EMSA-PKCSl-vl_5 encoding operation (Section 9.2.1) to the message 
Mto produce a second encoded message jEM' of length ^-1 octets: 

EM' = EMSA-PKCS1-v1_5-Encode (M, k-l) 

If the encoding operation outputs "message too long," then output "message too 
long" and stop. If the encoding operation outputs "intended encoded message 
length too short" then output "modulus too short". 

6. Compare the encoded message EM ^nd the second encoded message £Af . If they 
are the same, output *Valid signature"; otherwise, output "invaUd signature." 

9. Encoding methods 

Encoding methods consist of operations that map between octet string messages and 
integer message representatives. 

Two types of encoding method are considered in this docimient: encoding methods for 
encryption, encoding methods for signatures with appendix. 
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9-1 Encoding methods for encryption 

An encoding method for encryption consists of an encoding operation and a decoding 
operation. An encoding operation maps a message M to a message representative EM of a 
specified length; the decoding operation maps a message representative EM back to a 
message. The encoding and decoding operations are inverses. 

The message representative EM will typically have some structure that can be verified by 
the decoding operation; the decoding operation will output "decoding error" if the 
structure is not present. The encoding operation may also introduce some randomness, so 
that different applications of the encoding operation to the same message will produce 
different representatives. 

Two encoding methods for encryption are employed in the encryption schemes and are 
specified here: EME-OAEP and EME-PKCSl-vl_5. 

9.1.1 EME-OAEP 

This encoding method is parameterized by the choice of hash function and mask 
generation function. Suggested hash and mask generation functions are given in Section 
10. This encoding method is based on the method found in [2]. 



Figure 9-1 illustrates the encoding operation. 

9.1.1.1 Encoding operation 

EME-OAEP-Encode (M, P, emLen) 

Options: Hash hash function {hLen denotes the length in octets of the hash 

function output) 

MGF mask generation function 

Input: M message to be encoded, an octet string of length at most emLenA- 

IhLen 

P encoding parameters, an octet string 

emLen intended length in octets of the encoded message, at least 
IhLen-^l 

Output: EM encoded message, an octet string of length emLen\ or "message 

too long" or "parameter string too long" 
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Steps: 

1. If the length of P'is greater than the input limitation for the hash function (2^'-! 
octets for SHA-1) then output "parameter string too long" and stop. 

2. If IIMII > emLen-2hLen-\ then output "message too long" and stop. 

3. Generate an octet string PS consisting of emLen-\\M\\'2hLen'\ zero octets. The 
length oiPS may be 0. 

4. Let pHash = Hash{P\ an octet string of length hLen. 

5. Concatenate pHash, the message M, and other padding to form a data block 
DBzs 



DB^pHash II P5 II 01 ||M 



6. 


Generate a random octet string seed of length hLen. 


7. 


Let dhMask = MGF{seed, emLen-hLen). 


8. 


Let maskedDB = DB \xor dbMask. 


9. 


Let seedMask = MGF{maskedDB, hLen). 


10. 


Let maskedSeed = seed \xor seedMask. 


11. 


Let EM = maskedSeed \\ maskedDB. 


12. 


Output EM. 
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Figure 9-1: EME-OAEP 



9.1.1.2 Decoding operation 

EME-OAEP-Decode (EM, P) 

Options: Hash hash function (hLen denotes the length in octets of the hash 

function output) 



MGF mask generation function 
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Input: EM encoded message, an octet string of length at least 2hLen-^\ 

P encoding parameters, an octet string 

Output: M recovered message, an octet string of length at most 
2hLen\ or "decoding error" 

Steps: 

1. If the length of P is greater than the input hmitation of the hash function (2^*-l 
octets for SHA-1) then output "decoding error" and stop. 

2. If ll^A^I < 2hLen+\ , then output "decoding error" and stop. 

3. Let maskedSeed be the first hLen octets of EM and let maskedDB be the 
remaining ||£A^| - hLen octets. 

4. Let seedMask = MGF{maskedDB, hLen). 

5 . Let seed = maskedSeed \xor seedMask. 

6. Let dbMask = MGF{seed, \\EM\\ - hLen). 

7. LtX DB^ maskedDB \yior dbMask. 

8. Let pHash = Hash{P\ an octet string of length hLen. 

9. Separate DB into an octet string pHash ' consisting of the first hLen octets of DB, 
a (possibly empty) octet string PS consisting of consecutive zero octets following 
pHash \ and a message M as 

DB=pHash'\\PS\\Q\ \\M 

If there is no 01 octet to separate PS fi-om M, output "decoding error" and stop. 

10. If pHash' does not equal pHash, output "decoding error" and stop. 

11. Output M 

9.1.2 EME-PKCSl-vl_5 

This encoding method is the same as in PKCS #1 vl.5, Section 8: Encryption Process. 
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9.1.2.1 Encoding operation 

EME-PKCS1-v1_5-EnC0DE (M, emLen) 

Input: M message to be encoded, an octet string of length at most emLen-lO 

emLen intended length in octets of the encoded message 

Output: EM encoded message, an octet string of length emLen; or "message too 
long" 

Steps: 

1. If the length of the message M is greater than emLen - 10 octets, output "message 
too long" and stop. 

2. Generate an octet string PS of length emLen-\\M\\-2 consisting of pseudorandomly 
generated nonzero octets. The length of P5 will be at least 8 octets. 

3. Concatenate P5, the message M, and other padding to form the encoded message 
EMas 

£M=02||PS1|001|M 

4. Output £M. 

9.1.2.2 Decoding operation 

EME-PKCS1-v1_5-Decode (EM) 

Input: EM encoded message, an octet string of length at least 10 

Output: M recovered message, an octet string of length at most H^A/ll-lO; or 

"decoding error*' 

Steps: 

1 . If the length of the encoded message EM is less than 10, output "decoding error" 
and stop. 

2. Separate the encoded message EM into an octet string PS consisting of nonzero 
octets and a message M as 

£M= 02 II PS II 00 II M. 

If the first octet of EM is not 02, or if there is no 00 octet to separate PS from M, 
output "decoding error" and stop. 
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3. If the length of PS is less than 8 octets, output "decoding error" and stop. 

4. Output Af. 

9.2 Encoding methods for signatures with appendix 

An encoding method for signatures with appendix, for the purposes of this document, 
consists of an encoding operation. An encoding operation maps a message M to a 
message representative EM of a specified length. (In future versions of this document, 
encoding methods may be added that also include a decoding operation.) 

One encoding method for signatures with appendix is employed in the encryption 
schemes and is specified here: EMSA-PKGSl-vl_5. 

9.2.1 EMSA-PKCSl-vl_5 

This encoding rhethod only has an encoding operation. 
EMSA-PKCS1-v1_5-Encode (M, emien) 

Option: Hash hash function {hLen denotes the length in octets of the hash 

function output) 

Input: M message to be encoded 

emLen intended length in octets of the encoded message, at least ||ri| + 
10, where T is the DER encoding of a certain value computed 
during the encoding operation 

Output: EM encoded message, an octet string of length emLen; or "message too 

long" or "intended encoded message length too short" 

Steps: 



1 . Apply the hash function to the message M to produce a hash value H: 

H = Hash{M). 

If the hash function outputs "message too long," then output "message too long". 

2. Encode the algorithm ID for the hash function and the hash value into an ASN.l 
value of type Digest Info (see Section 11) with the Distinguished Encoding 
Rules (DER), where the type Digest Info has the syntax 
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Digestlnfo ::= SEQUENCE { 

digestAlgorithm Algorithmldentif ier , 
digest OCTET STRING } 

The first field identifies the hash function and the second contains the hash value. 
Let T be the DER encoding. 

3. IfemLen is less than ||J1| + 10 then output "intended encoded message length too 
short". 

4. Generate an octet string PS consisting of emLen'\\T\\-2 octets with value FF 
(hexadecimal). The length of ^5 will be at least 8 octets. 

5. Concatenate PS, the DER encoding 7, and other padding to form the encoded 
message EM as 

EM=Q\\\PS\\m\\T 

6. Output EM. 

10. Auxiliary functions 

This section specifies the hash functions and the mask generation functions that are 
mentioned in the encoding methods (Section 9). 

10.1 Hash functions 

Hash functions are used in the operations contained in Sections 7, 8 and 9. Hash functions 
are deterministic, meaning that the output is completely determined by the input. Hash 
functions take octet strings of variable length, and generate fixed length octet strings. The 
hash functions used in the operations contained in Sections 7, 8 and 9 should be collision 
resistant This means that it is infeasible to find two distinct inputs to the hash function 
that produce the same output. A collision resistant hash function also has the desirable 
property of being one-way; this means that given an output, it is infeasible to find an 
input whose hash is the specified output. The property of collision resistance is especially 
desirable for RSASSA-PKCSl-vl_5, as it makes it infeasible to forge signatures. In 
addition to the requirements, the hash function should yield a mask generation function 
(Section 10.2) with pseudorandom output. 

Three hash functions, are recommended for the encoding methods in this document: MD2 
[15], MD5 [17], and SHA-1 [16]. For the EME-OAEP encoding method, only SHA-1 is 
recommended. For the EMSA-PKCSl-vl_5 encoding method, SHA-1 is recommended 
for new applications. MD2 and MD5 are recommended only for compatibility vvdth 
existing applications based on PKCS #1 vl.5. 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 v2.0: RSA^ 



m 



; OGRAPHY Standard 



The hash functions themselves are not defined here; readers are referred to the 
appropriate references ([15], [17] and [16]). 

Note, Version 1.5 of this document also allowed for the use of MD4 in signature 
schemes. The cryptanalysis of MD4 has progressed significantly in the intervening years. 
For example, Dobbertin [10] demonstrated how to find collisions for MD4 and that the 
first two rounds of MD4 are not one-way [11]. Because of these results and others (e.g. 
[9]), MD4 is no longer recommended. There have also been advances in the cryptanalysis 
of MD2 and MD5, although not enough to warrant removal from existing applications. 
Rogier and Chauvaud [19] demonstrated how to find collisions in a modified version of 
MD2. No one has demonstrated how to find collisions for the full MD5 algorithm, 
although partial results have been found (e.g. [8]). For new applications, to address these 
concerns, SHA-1 is preferred. 

10.2 Mask generation functions 

A mask generation function takes an octet string of variable length and a desired output 
length as input, and outputs an octet string of the desired length. There may be 
restrictions on the length of the input and output octet strings, but such bounds are 
generally very large. Mask generation functions are deterministic; the octet string output 
is completely determined by the input octet string. The output of a mask generation 
function should be pseudorandom, that is, if the seed to the function is unknown, it 
should be infeasible to distinguish the output fi-om a truly random string. The plaintext- 
awareness of RSAES-OAEP relies on the random nature of the output of the mask 
generation function, which in tum relies on the random nature of the underlying hash. 

One mask generation function is recommended for the encoding methods in this 
document, and is defined here: MGFl, which is based on a hash fimction. Future versions 
of this document may define other mask generation functions. 

10.2.1 MGFl 

MGFl is a Mask Generation Function based on a hash function. 
MGFl iZ,l) 

Options: Hash hash function {hLen denotes the length in octets of the hash 



function output) 



Input: 



Z 



seed fi-om which mask is generated, an octet string 



/ 



intended length in octets of the mask, at most 2 hLen 



Output: 



mask 



mask, an octet string of length /; or "mask too long' 
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Steps: 

1 . If / > 2^^ ALen, output "mask too long" and stop. 

2. Let T be the empty octet string. 

3 . For counter from 0 to F / / hLen 1- 1 , do the following: 

a. Convert counter to an octet string C of length 4 with the primitive I20SP: 

C^UOS? (counter, 4) 

b. Concatenate the hash of the seed Z and C to the octet string T: 

T=-T\\Hash{Z\\Q 

4. Output the leading / octets of 7 as the octet string mask, 

11. ASN.l 

11.1 Key representation 

This section defines ASN.l object identifiers for RSA public and private keys, and 
defines the types RSAPublicKey and RSAPrivateKey. The intended application of 
these definitions includes X.509 certificates, PKCS #8 [22], and PKCS #12 [23]. 

The object identifier rsaEnciryption identifies RSA public and private keys as 
defined in Sections 11.1.1 and 11.1.2. The parameters field associated with this ODD 
in an Algorithml dent if ier shall have type NULL. 

rsaEncryption OBJECT IDENTIFIER ::= {pkcs-1 l} 

All of the definitions in this section are the same as in PKCS #1 vL5. 

11.1.1 Public-key syntax 

An RSA public key should be represented with the ASN.l type RSAPubl icKey: 

RSAPublicKey : := SEQUENCE { 
modulus INTEGER, n 
publicExponent INTEGER e } 

(This type is specified in X.509 and is retamed here for compatibility.) 
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The fields of type RSAPubl icKey have the following meanings: 

• modulus' is the modulus n. 

• publicExponent is the public exponent e. 

11.1,2 Private-key syntax 

An RSA private key should be represented with ASN. 1 type RSAPr i vat eKey: 

RSAPrivateKey ::= SEQUENCE { 
version Version/ 
modulus INTEGER, n 
publicExponent INTEGER, e 
privateExponent INTEGER, d 
primel INTEGER, -- p 
prime2 INTEGER, q 
exponentl INTEGER, d mod (p-1) 
exponent2 INTEGER, d mod (q-l) 
coefficient INTEGER (inverse of q) mod p } 

Version ::= INTEGER 

The fields of type RSAPrivateKey have the following meanings: 

• version is the version number, for compatibility with future revisions of 
this document. It shall be 0 for this version of the document. 

• modulus is the modulus n. 

• publ i cExponent is the public exponent e. 

• privateExponent is the private exponent d. 

• primel is the prime factor p of «. 

• prime2 is the prime factor qofn. 

• exponentl is J mod (p-1). 

• exponent 2 is d mod (g-l). 

• coefficient is the Chinese Remainder Theorem coefficient q'^ mod p. 
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11.2 Scheme identification 

This section defines object identifiers for the encryption and signature schemes. The 
schemes compatible with PKCS #1 vl.5 have the same definitions as in PKCS #1 vL5. 
The intended application of these definitions includes X.509 certificates and PKCS #7, 

1 1 .2.1 Syntax for RS AES-O AEP 

The object identifier id-RSAES-OAEP identifies the RSAES-OAEP encryption scheme. 

id-RSAES-OAEP OBJECT IDENTIFIER ::= {pkcs-1 7} 

The parameters field associated with this OED in an Algorithmldentif ier shall 
have type RSAEP-OAEP-params : 

RSAES-OAEP-params ::= SEQUENCE { 

hashFunc . [0] Algorithmldentif ier { {oaepDigestAlgorithms} } 

DEFAULT shalldentif ier, 
maskGenFunc [1] Algorithmldentif ier { (pkcslMGFAlgorithms) } 

DEFAULT mgf ISHAlIdentif ier, 
pSourceFunc [2] Algorithmldentif ier 

{ {pkcslpSourceAlgorithms} } 

DEFAULT pSpecif iedEmptyldentif ier } 

The fields of type RSAES-OAEP-params have the following meanings: 

• hashFunc identifies the hash function. It shall be an algorithm ID with an OID in 
the set oaepDigestAlgorithms, which for this version shall consist of id- 
shal, identifying the SHA-1 hash function. The parameters field for id-shal 
shall have type NULL. 

oaepDigestAlgorithms* ALGORITHM- IDENTIFIER ::= { 
{NULL IDENTIFIED BY id-shal} } 

id-shal OBJECT IDENTIFIER ::= 

{iso{l) identif ied-organization(3) oiw(14) secsigO) 
algorithms (2) 26} 

The default hash function is SHA-1 : 
shalldentif ier : := Algorithmldentif ier {id-shal, NULL} 

• maskGenFunc identifies the mask generation function. It shall be an algorithm ID 
with an OID in the set pkcslMGFAlgorithms, which for this version shall consist 
of id-mgf 1, identifying the MGFl mask generation function (see Section 10.2.1). 
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The parameters field for id-mgf 1 shall have type Algorithmldentif ier, 
identifying the hash function on which MGFl is based, where the OID for the hash 
function shall be in the set oaepDiges.tAlgorithms. 

pkcslMGFAlgorithms ALGORITHM- IDENTIFIER ::= { 

{Algorithmldentif ier { {oaepDigest Algorithms } } IDENTIFIED 
BY id-mgfl} } 

id-mgfl OBJECT IDENTIFIER ::= {pkcs-1 8} 

The default mask generation function is MGFl with SHA-1: 

mgf ISHAlIdentif ier ::=• Algorithmldentif ier { 
id-mgfl, shalldentif ier } 

• pSourceFunc identifies the source (and possibly the value) of the encoding 
parameters P, It shall be an algorithm ID with an OID in the set 
pkcslpSourceAlgorithms, which for this version shall consist of id- 
pSpecif ied, indicating that the encoding parameters are specified explicitly. The 
parameters field for id-pSpecif ied shall have type OCTET STRING, 
containing the encoding parameters. 

pkcslpSourceAlgorithms ALGORITHVI- IDENTIFIER { 
(octet string IDENTIFIED BY id-pSpecif ied} } 

id-pSpecified OBJECT IDENTIFIER ::= {pkcs-1 9} 

The default encoding parameters is an empty string (so that pHash in EME-OAEP 
will contain the hash of the empty string): 

pSpecif iedEmptyldentif ier Algorithmldentif ier { 

id-pSpecif ied, OCTET STRING SIZE (0) } 

If all of the default values of the fields in RSAES-OAEP-params are used, then the 
algorithm identifier will have the following value: 

RSAES-OAEP-Def ault-Identif ier ::= Algorithmldentif ier { 
id-RSAES-OAEP, 
{shalldentif ier, 
mgf ISHAlIdentif ier, 
pSpecif iedEmptyldentif ier } } 
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12. Revision history 
Versions 1.0-1.3 

Versions 1.0-1.3 were distributed to participants in RSA Data Security, Inc.*s Public-Key 
Cryptography Standards meetings in February and March 1991. 

Version 1.4 

Version 1.4 was part of the June 3, 1991 initial public release of PKCS. Version 1.4 was 
published as NIST/OSI Implementors' Workshop document SEC-SIG-91-18. 

Version 1.5 

Version 1.5 incorporated several editorial changes, including updates to the references 
and the addition of a revision history. The following substantive changes were made: 

•Section 10: "MD4 with RSA" signature and verification processes were added. 
•Section 11: md4WithRSAEncryption object identifier was added. 
Version 2.0 

Version 2.0 incorporates major editorial changes in terms of the document structure, and 
introduces the RSAEP-OAEP encryption scheme. This version continues to support the 
encryption and signature processes in version 1.5, although the hash algorithm MD4 is no 
longer allowed due to cryptanalytic advances in the intervening years. 

13. References 

[1] ANSI, ANSI X9A4: Key Management Using Reversible Public Key Cryptography 
for the Financial Services Industry, Working Draft. 

[2] M. Bellare and P. Rogaway. Optimal Asymmetric Encryption-How to Encrypt with 
RSA. In Advances in Cryptology-Eurocrypt '94, pp. 92-1 1 1, Springer-Veriag, 1994. 

[3] M. Bellare and P. Rogaway. The Exact Security of Digital Signatures-How to Sign 
with RSA and Rabin. In Advances in Cryptology-Eurocrypt '96, pp. 399-416, 
Springer- Verlag, 1996. 

[4] D. Bleichenbacher. Chosen Ciphertext Attacks against Protocols Based on the RSA 
Encryption Standard PKCS #7. To appear in Advances in Cryptology-Crypto '98, 

[5] D. Bleichenbacher, B. Kaliski and J. Staddon. Recent Results on PKCS #1: RSA 
Encryption Standard. RSA Laboratories' Bulletin, Number 7, June 24, 1998. 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 v2.0: RSA^Ti Vjgraphy STANDARD 



35 



[6] CCITT. Recommendation X.509: The Directory-Authentication Framework. 1988. 

[7] D. Coppersmith, M. Franklin, J. Patarin and M. Reiter. Low-Exponent RSA with 
Related Messages. In Advances in Cryptology-Eurocrypt '96, pp. 1-9, Springer- 
Verlag, 1996. 

[8] B. den Boer and Bosselaers. Collisions for the Compression Function of MD5. 
Advances in Cryptology-Eurocrypt '93, pp. 293-304, Springer- Verlag, 1994. 

[9] B. den Boer, and A. Bosselaers. An Attack on the Last Two Rounds of MD4. In 
Advances in Ciyptology-Crypto '91, pp.194-203, Springer-Verlag, 1992. 

[10] H. Dobbertin. Cryptanalysis of MD4. Fast Software Encryption. Lecture Notes in 
Computer Science, Springer-Verlag 1996, pp. 55-72. 

[11] H. Dobbertin. Cryptanalysis of MD5 Compress. Presented at the rump session of 
Eurocrypt ' 96, May 1 4, 1 996 

[12] H. Dobbertin. 77ie First Two Rounds of MD4 are Not One-Way. Fast Software 
Encryption. Lectiire Notes in Computer Science, Springer-Verlag 1998, pp. 284-292. 

[13] J. Hastad. Solving Simultaneous Modular Equations of Low Degree. SLAM Journal 
of Computing, 17, 1988, pp. 336-341. 

[14] IEEE. IEEE P1363: Standard Specifications for Public Key Cryptography. Draft 
Version 4. 

[15] B. Kaliski. RFC 1319: The MD2 Message-Digest Algorithm. Internet Activities 
Board, April 1992. 

[16] National Institute of Standards and Technology (NIST). FIPS Publication 180-1: 
Secure Hash Standard. April 1 994. 

[17] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. Internet Activities 
Board, April 1992. 

[18] R. Rivest, A. Shamir and L. Adleman. A Method for Obtaining Digital Signatures 
and Public-Key Cryptosystems. Communications of the ACM, 21(2), pp. 120-126, 
February 1978. 

[19] N. Rogier and P. Chauvaud. The Compression Function of MD2 is not Collision 
Free. Presented at Selected Areas of Cryptography '95. Carleton University, Ottawa, 
Canada. May 18-19, 1995. 

[20] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 1.5, November 
1993. 



Copyright © 1991-1998 RSA Laboratories. 



PKCS #1 v2.0: RSA^Fi- . jgraphy Standard 



36 



[21] RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. Version 
1.5, November 1993. 

[22] RSA Laboratories. PKCS #5; Private-Key Information Syntax Standard. Version 
1.2, November 1993. 

[23] RSA Laboratories. PKCS #12: Personal Information Exchange Syntax Standard. 
Version 1.0, DRAFT, April 1997. 



Copyright © 1991-1998 RSA Laboratories. 



-o 

X 



FEB> 0 5 2003 



RECEIVED^ 

Technology Center 21p0 





RECEIVED 

FEB 1 9 M 

Technology Center 21 00 



o 
o 



m 
a 
8 

CD. 

a. 



O 

D» 



CD 

m 



CI 

o 



o ^ 



< 



S IS 

il O 



CD 
O 

3 

^. 

5' 

(O 

> 
a 

Q. 

-«i 

(D 
(A 
0) 



-n w > 



85 



o 

c 

— » 

CD 



0 0) X 

5^ 3 III 

Z M &i 

Ii5 = i. 

2 » Si. 

^ "O ISO 

-Is 

1 5 

g o 



^ 2 o 

C a* 
o J? 

m o> 
-< 1^ 

^ 00 

"D 
H 
O 
O 

13 
X 

o 
> 

TJ 
TJ 
> 

H 
C 

> 

z 
o 

m 

H 
X 
O 
O 



^ "0 
(D 0) 



O CD 

:. (D 



55 O 

CO P 

00 

Vi Z 

lo CO 

0> (D 



m I 
o m 
ED CO 

m H 
O "1 

o w 



> 
z 
o 



> 



o 
o 

3 



D 

m 
> 

O 
TJ m 

§^ 

□ g 



8 



RECEIVED 

FEB 1 9 2013 




® 



-li. 



EXPRESS 

miL 

UmePSnTESPpSTALSERVICEIB) 




POST OFFICE 
TO ADDRESSEE 



EL 7M5DblQH3 US 



9 

Si 

St. 




FROM: (PLEASE PRINT) 

r 



OPPe^^i^rpl.ffi-r^ * CONNELLY 



gtoioUf 



ASSISTANT comts^imm 



FOR F-AXtPiTS,.... 
WASHINGTON 



Dc' 20231-0001 



fOBPICKUPORmCKINGCAa 1.800-222-1.11 ™«W.»spS.c™ ^ 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ black borders 

□ dkIage cut off at top, bottom or sides 



□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




FADED TEXT OR DRAWING 



